One ongoing problem in developing computer software application programs is how to implement policy constraints. As used herein, the term “policy” is used broadly to refer to any rule or condition that can be applied to data. Example policies include, without limitation, network management policies, data access policies and security policies. The particular policies implemented for application programs vary widely depending upon the requirements and context of a particular application program.
Policy constraints are conventionally applied to application programs by an application programmer who updates application program code to include “calls”, or invocations, to policy routines. The application programmer typically also adds program logic statements to the application program code in association with the calls to the policy routines. The purpose of the program logic statements is to make the execution of a set of code statements conditioned upon a particular result of calling a policy routine. For example, policy routines commonly return a value that indicates the result of applying a set of policy constraints. The return value is examined and particular steps are taken by the application program depending upon the particular return value.
For example, suppose that an application programmer updates an application program to include a call to an authentication routine to authenticate a particular user. The authentication routine applies a set of policy constraints and returns a value that specifies a level of access that should be provided to the particular user. For example, the authentication routine may verify the identity of the particular user and then check the access rights of the particular user. Application program logic, e.g., a “switch” statement in the programming language C, then processes the return value and determines an appropriate action to be taken based upon the level of access specified for the particular user.
The policy routines themselves may be linked into an application program executable, for example by being included in a routine library. Alternatively, policy routines may instead be located on a remote node in distributed computing applications and invoked using a remote procedure call (RPC) mechanism.
Consider the following example. FIG. 1 is a block diagram that depicts a conventional arrangement 100 for implementing policies in application programs. An application program 102 includes program code that invokes general routines 104 to perform the functions generally required by application program 102, such as data processing and input/output (I/O) operations. General routines 104 may include “low level” routines, such as operating system I/O routines and device drivers, as well as higher-level routines that may themselves call the low level routines. General routines 104 are generally developed separately from the program code contained in application program 102 and then linked into application program 102.
Application program 102 invokes policy routines 106 to apply policy constraints. For example, application program 102 may invoke an authorization routine from policy routines 106 to authenticate a user. Based upon the results of executing the authorization routine, program logic contained in application program 102 either allows or disallows certain functionality.
Although application program 102, general routines 104 and policy routines 106 are depicted in FIG. 1 as separate entities, in practice, general routines 104 and policy routines 106 may be part of application program 102. This may be accomplished, for example, using a variety of techniques, such as a linked code library. In this context, links 108, 110 are typically one or more names or addresses associated with general routines 104 and policy routines 106. Alternatively, in a distributed computing environment, general routines 104 and policy routines 106 may be located on different nodes than the node on which application program 102 resides and may be invoked using remote invocation techniques, such as an RPC mechanism. In this context, links 108, 110 may be implemented by any medium or mechanism that provides for the exchange of data between A and B. Examples of links 108, 110 include, without limitation, a network such as a Local Area Network (LAN), Wide Area Network (WAN), Ethernet or the Internet, or one or more terrestrial, satellite or wireless links.
One significant drawback of the aforementioned conventional approach for applying policy constraints in application programs is that the approach is generally very intrusive because it requires making the application program code policy “aware.” In other words, the application program code must be updated to include the functionality associated with applying the desired policy constraints. This requires the application programmer to know what policy routines need to be called, and under what conditions, to apply particular policy constraints. The application programmer must also modify the application program code to include program logic to process the return codes provided by the policy routines. If new policy constraints are added, then the application program code must be updated to handle the new constraints. These tasks place a large burden on application programmers and are very intrusive.
Based upon the foregoing, there is a need for an approach for applying policy constraints in application programs that does not suffer from the limitations of prior approaches.
There is a particular need for an approach for applying policy constraints in application programs that is less intrusive to application programs than conventional approaches.
There is a further need for an approach for applying policy constraints in application programs that provides for separation of the functionality associated with applying policy constraints from application program code.